查看原文
其他

让【在浏览器地址栏输入一个URL后回车,背后会进行哪些技术步骤?】成为面试的加分点

车小胖谈网络 帅地玩编程 2022-06-18

来源:车大胖谈网络

作者:车大胖谈网络。

苦逼的码农作了一些修改。


这个问题,可是说是面试中最高的考点了,覆盖了计算机网络的大部分知识,一般你描述的越详细,能拿到的分数就越高吧,这篇文章讲的还不错,各位小伙伴可慢慢品读,对计算机网络不怎么懂的可以看我先看我写的这篇文章:一文读懂一台计算机是如何把数据发送给另一台计算机的


为了让更多读者理解这个问题,接下来派出男主角小明出场,采用拟人的手法来阐述整个过程。

 

小明听说最近两天知乎有一个帖子挺火,问题的提出者是腾讯的总裁 Pony Ma,有一个回答是这样的:

 

 

于是小明想去看看精彩评论,于是开始了网上冲浪之旅。。。

 

小明打开浏览器,输入zhihu.com敲回车键。

 

1、格式验证与协议选择


在小明眼里,浏览器是自己的小奴才,让你干啥就干啥。


浏览器才不这么看,鄙人也是有自己独立的人格的,老板的命令如果是对的,那自然照做。那如果是错误的,那就不能听命不是?

 

如果小明输入的是 “zhi hu.com” 或 “zhi@hu.com1”, 这些网址都是非法无效的,浏览器就要拒绝小明的无理要求,提示小明出错了。

 

所以,第一步是浏览器对用户输入的网址做初步的格式化检查,只有通过以上检查才会进入下一步。

 

浏览器是用http还是https访问服务器呢?

小明并没有明确告知浏览器是用哪个协议,针对此种情况,浏览器有自己的预案,那就是默认使用http协议,除非小明输入的是“https://zhihu.com”。

 

所以,小明输入的网址被浏览器补齐为“http://zhihu.com” 。

 

2、DNS 查询


浏览器知道,TCP/IP快递公司那帮王八蛋,只有告诉它们收件人的IP地址,才会把快递送到收件人地址。告诉他们  “zhihu.com”如同对牛弹琴,它们不懂啊!

 

浏览器于是联系“黄页公司” DNS,请帮我查询一下“zhihu.com”  的IP地址是多少?

 

DNS是个老实孩子,自己能查询到的,绝不麻烦别人。

 

先查自己内存里的DNS Cache,没有!

再查本地硬盘里的host文件,也没有!

 

实在没辙只有求人了,于是DNS硬着头皮去联系自己的DNS服务器 8.8.8.8。(注:不一定是8.8.8.8,可以自己静态配置也可以动态获取)

 

DNS将自己的查询打好包,收件人地址为8.8.8.8,寄件人地址为1.1.1.1,DNS联系TCP/IP快递公司。

 

负责接洽的是UDP,UDP懒洋洋的躺在沙发上,随手在包裹上刷刷写了几笔:

 

收件人门牌号   53

发件人门牌号   56002

这个就相当于端口号,同时也要知道,DNS 是采用 UDP 协议。


之所以要有门牌号,是因为一个收件人地址可能会有多个门牌号,为了避免混淆。对于整天浸淫在快递行业的UDP,太了解这个行业了。

 

UDP给货车司机IP打电话:老四啊,有件快递需要你捎带一下。。。


IP司机来了,把包裹扔上车,坐上驾驶座,准备开车。

 

IP司机查询了导航(IP路由表),发现要出关(Gateway),这个关口有点怪癖,需要司机要知道其MAC地址,导航信息里竟然没有。

 

于是IP司机找到了当地向导ARP,老师傅,麻烦您带带路啊!

 

ARP没有废话,声音洪亮地喊了一嗓子,网关你MAC地址多少啊,告诉老夫一声!

很快传来了网关的回答:我的MAC地址是xx.xx.xx.xx.xx.xx

 

有了关口的MAC地址,IP司机终于可以开车上路了。

 

很快就到达了关口,关口放行,IP司机载着快递,上了Internet高速公路,一路狂奔不表。。。

 

到达目的地8.8.8.8,服务器根据门牌号码53,知道这是DNS Server大叔家的快递。

 

喊大叔来收快递,大叔打开包裹一看,这个好回答啊,zhihu.com对应的IP地址正好在缓存里还热着呢,于是将其回复回去。

 

这个DNS大叔有一个特点,打破沙锅问到底的学习精神,俗称的一根筋。如果DNS大叔的本地缓存里查询没有,怎么办呢?

 

DNS大叔会去联系DNS域名系统的根服务器“.”

 

有读者会问,“.”代表的就是根服务器?

 

对的,我们经常看到的网址如zhihu.com,完整的写法应该是 zhihu.com. 最后的那个“.”相当于树根,天下所有的叶子域名,都是树根的孩子、孩子的孩子....

 

根域名服务器全球一共多少台?

13台

 

1台不行吗?

万一根服务器挂了,会影响全球的域名查询系统。使用多台根服务器,可以提供物理冗余,分摊全球的域名查询任务。

 

DNS大叔知道13台根服务器的IP地址吗?

知道。

 

DNS大叔就会去联系13台根服务器的一员,查询自己想要的结果。

 

根服务器一看“zhihu.com.” ,知道是自己的孙子,却不知道其IP地址。但根服务器相信孙子的爸爸“com”会知道,于是告诉DNS大叔,请去联系我孙子的爸爸,他的IP地址是x.x.x.x。

 

DNS大叔锲而不舍地去联系孙子的爸爸,毫无疑问,爸爸肯定知道儿子的IP地址,儿子的名字都是自己起的,能不知道吗?

 

将结果告诉了DNS大叔,大叔如获至宝,立马将结果告诉了远在千里之外等待的DNS老实孩子,结果应该是这个样子的:

 

 

累死了,鼓捣了半天才算拿到服务器的IP地址,DNS把结果返回给浏览器。

 

3、三次握手


浏览器再次联系TCP/IP快递公司,这次与其接洽的是TCP阿姨,TCP做事非常认真。

 

知道浏览器想要去拜访“118.89.204.100”,先和对方取得联系,看看对方在不在,这通常由三次握手实现的。

 

老阿姨:在家吗?想去拜访您。

对方:在的,欢迎啊。

老阿姨:马上到。

 

这一来二回的三次消息,也都需要IP司机来来回回运输三次,具体过程和上文IP司机运输DNS报文非常类似,就不再重复。

 

三次握手完成,TCP阿姨与对方建立了一个可靠的虚拟通道,浏览器很快知道了这个消息。

 

浏览器将http请求消息,打包好扔给TCP阿姨,阿姨在包裹上填上关键信息:

 

收件人门牌号  80

发件人门牌号  51235

 

然后也是联系IP司机来运输,过程不表。

 

包裹到达了目的地,服务器根据门牌号80,联系到了http server小姐姐。

 

小姐姐返回了一个消息:HTTP Redirect 消息,大意是,本公司服务器整体搬迁到https://www.zhihu.com上去了,请重新访问本司的新网址。

 

 

注意,此时是采用 https 协议了。


浏览器收到这个消息,立马前往https://www.zhihu.com,整个过程与http:/zhihu.com大体相似,接下来主要阐述不一样的地方。

 

TCP三次握手成功之后,浏览器将自己的打包好的包裹,不是直接给TCP阿姨,而是委托TLS安保大叔全权负责。

 

由于 http 是明文传输的会不安全,而 https 协议是加密的、安全的,需要经过证书验证等步骤,不懂 https 的可以看我这篇文章:【漫画】https 加密那点事


TLS安保大叔,首要的任务是确保包裹在运输过程中的安全,即包裹的内容保密,包裹内容不能被篡改、替换。

 

TLS大叔需要先和对方沟通安保措施,沟通的渠道,就是上文三次握手建立的渠道。

 

TLS大叔先发言:你好,我支持TLS版本1.2,以及我的认证算法、加密算法、数据校验算法,此外还有我的随机码,收到请回复。

 

TLS服务器回复:你好,我也支持1.2版本,那我们就使用xx认证算法、xx加密算法、xx数据校验算法,我的随机码是xx,来实现安保措施,你看好吗?

 

TLS大叔:没问题啊,能出示一下你的证件(数字证书)吗?

TLS服务器:okay,这是我的证件,请过目。

 

 

TLS大叔发现对方发过来两个证书:

证书1: “*.zhihu.com”,由GeoTrust RSA CA 2018签名并颁发
证书2: “GeoTrust RSA CA 2018”,由DigiCert Global Root CA签名并颁发


验证过程如下:

1.用DigiCert Global Root CA的公钥解密证书2的签名

DigiCert Global Root CA作为一个权威CA,已经被浏览器预先安装在可信任根证书列表,那么我们信任该CA的一切,当然包括其公钥,在该证书里包含了明文的公钥,如下图所示:

 



解开了,证明是该CA私钥加密的,由于CA私钥只有CA知道,证书有效,并信任GeoTrust RSA CA 2018公钥

解不开,证明不是CA私钥加密,无效证书。



2. 用GeoTrust RSA CA 2018的公钥解密证书1的签名

过程和步骤1同样的原理,如果2个步骤都验证成功,就有了zhihu.com的公钥。

TLS大叔还需要检查的证书有效期,再检查证书是否被吊销(CRL),如果一切都没有问题,进入下一个步骤。


TLS大叔用“*.zhihu.com”公钥加密一段随机的字符串,发送给TLS服务器。

TLS服务器用自己的私钥解密,得到明文字符串。

 

至此,双方分享了这个神秘的字符串,双方还有早前分享的随机码(nonce),双方使用同样的算法,可以推导出相同的master key,进而推导出session key、HMAC key。

 

Session Key用于加密/解密数据, HMAC Key主要用于保护数据的完整性,以防被第三方篡改。

 

整个TLS沟通过程就算完成了,TLS大叔把浏览器扔给自己的包裹,外面加了一层保险箱,密码锁(session key)只有TLS大叔、TLS服务器知道。

 

然后把保险箱再扔给TCP阿姨,TCP阿姨一点也不在乎,运输一个保险箱与一个普通包裹没有任何区别,唯一的区别是收件人的门牌号变了:

 

收件人门牌号  443

 

然后保险箱就被运走了,很快就到达了目的地,服务器老大爷一看门牌号443,知道这是TLS服务器的快递包裹。

 

TLS服务器用密码打开了保险箱,取出了快递。

 

在保险箱里还有一个小纸条写着“Application Data =http”, TLS大叔知道这是HTTP Server高富帅的包裹。

 

然后把包裹转交给高富帅,高富帅将www.zhihu.com 主页返回,并最终到达浏览器。

 

小明很快就搜索到本文开始的那个回答,小明做梦都没有想到,自己的一次回车键,引发如此庞大的计算量。。。


推荐阅读:

HTTP协议入门

【漫画】https 加密那点事一文读懂一台计算机是如何把数据发送给另一台计算机的



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存